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REMARKS 

By this amendment, Claims 10, 14, 21, 25, 32, 36, 43, 46, and 53 are amended, Claims 1- 
9, 1 1, 13, 15, 22, 24, 26, 33, 35, 37, 45, and 47 are canceled, and no claims are added. Hence, 
Claims 10, 12, 14, 16-21, 23, 25, 27-32, 34, 36, 38-44, 46, and 48-56 are pending in the 
application. 

The amendments to the claims as indicated herein do not add any new matter to this 
application. Instead, the amendments to the independent claims incorporate the subject matter of 
the corresponding canceled claims. For example, Claim 10 now includes the subject matter of 
canceled Claims 11, 13, and 15. Canceled Claim 15 depended on canceled Claim 13, which 
depended on canceled Claim 1 1, which depended on Claim 10. Claim 10 contains the same 
subject matter and scope of canceled Claim 15. Therefore, no new search is required. 

Each issue raised in the Office Action mailed April 7, 2008 is addressed hereinafter. 

I. SOLE REJECTION 

Claims 1-56 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable over 
U.S. Patent No. 5,008,814, in view of U.S. Patent Application No. 2005/0198629. This rejection 
is respectfully traversed. 

A. CLAIM 10 

Claim 10 now recites: 

A method of software loading and initialization in a distributed network of nodes, 
the method comprising: 

persistently storing, in a first storage of a master node, a plurality of software 

packages and a plurality of boot images, wherein the plurality of software 
packages and the plurality of boot images will be used by the nodes in the 
distributed network; 

persistently storing, in a second storage of the master node, software version 
information and node type information for each node in the distributed 
network; 
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receiving, at the master node, a request for a boot image and software packages 
from a node, in the distributed network, that is performing an initial boot; 

based on the request, the master node determining software version information of 
the node to retrieve from the second storage; 

the master node retrieving the software version information of the node from the 
second storage; 

the master node determining, based on the software version information of the 
node, a boot image of the plurality of boot images and one or more 
software packages of the plurality of software packages to extract from the 
first storage; 

the master node extracting the boot image and the one or more software packages 
from the first storage; 

delivering, to the node, the boot image and the one or more software packages, 

wherein said node stores the boot image and the one or more software packages in 
its local persistent storage and wherein software version information is 
extracted from the one or more software packages and stored in the 
local persistent storage, 

wherein said node reboots and executes the boot image stored in the local 

persistent storage, and wherein said node verifies the software version 
information with said master node; 

if said node does not have the correct software versions, then the master node 
retrieving correct software packages from the first storage and 
sending the correct software packages to said node, wherein said node 
stores the correct software packages in the local persistent storage and 
completes booting by executing the correct software packages stored 
in the local persistent storage, (emphasis added) 

At the least the above-bolded features of Claim 10 are not taught or suggested by Mathur or 

Vishwanath, either individually or in combination. 

1. The cited art fails to teach or suggest what happens if the software 
versions of software packages that a node receives are not correct 

On page 7, the Final Office Action cites the check consistency of FIG. 2 of Mathur for 

allegedly disclosing "if said node does not have the correct software versions, then the master 

node retrieving correct software packages from the first storage and sending the correct software 

packages to said node, wherein said node stores the correct software packages in the local 

persistent storage and completes booting by executing the correct software packages stored in the 

local persistent storage," as recited in Claim 10. This is incorrect. In fact, this cited portion of 

Mathur teaches away from this feature of Claim 10. The check consistency is referenced in 
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steps 202 and 207 of FIG. 2. As FIG. 2 depicts and as the corresponding text teaches, in both 

cases where the check consistency fails, old software is re-used. Specifically, contents of an 

"old" non- volatile storage device on a destination node (i.e., the alleged "node" of Claim 10) are 

copied either to a "dirty" non- volatile storage device (referred to as a "loadback process") of the 

destination node or to a "trial" non-volatile storage device (referred to as a "cutback process") of 

the destination node. What's more, the check consistency of step 202 occurs at the source node 

(i.e., the alleged "master node" of Claim 10) and occurs before any communication has even 

been made with any destination node . Fundamentally, the destination node of Mathur does not 

receive another set of software packages from the source node if the destination node does 

not have the correct software versions . Lastly, Vishwanath is not cited for teaching or suggesting 

this feature of present Claim 10. 

2. The cited art fails to teach or suggest that a node that receives software 
packages verifies software version information of the software packages 
with the master node 

On page 6, the Final Office Action also cites steps 204 and 21 1 of FIG. 2 of Mathur for 
allegedly disclosing "wherein the node verifies the software version information with said master 
node," as recited in Claim 10. This is also incorrect. In step 204, the source node of Mathur 
transmits new software to the destination node. In step 21 1, the destination node performs an 
update process which comprises copying the content of a "trial" non-volatile storage device to all 
of the other non- volatile storage devices of the destination node. In neither step does the 
destination node verify software version information with the source node, as this feature of 
Claim 10 requires. Indeed, the entire Mathur reference lacks any teaching or suggestion of a 
destination node verifying software version information with a source node, much less 
performing this verification step after the destination node receives software packages from the 
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source node. Lastly, Vishwanath is not cited for teaching or suggesting this feature of present 

Claim 10 

3. The cited art fails to teach or suggest that software version information is 
extracted from software packages that are delivered to a node from the 
master node 

On page 9, the Final Office Action cites col. 7, lines 32-53; col. 6, lines 41-54; and col. 3, 
lines 29-53 of Mathur for allegedly disclosing "wherein software version information is 
extracted from the one or more software packages and stored in the local persistent storage," as 
recited in Claim 10. This is incorrect. 

Col. 7, lines 32-53 of Mathur teaches a target or destination node performing a cutover 
process, a consistency check, and an IPL (i.e., an initial program boot). If the IPL fails, then the 
destination node performs a cutback process to revert to older software it was executing. 

Col. 6, lines 41-54 of Mathur teaches a destination node receiving data packets pertaining 
to new software that is distributed from a source node. The destination node computes a 
checksum of from the packets and compares that checksum to a checksum transmitted from the 
source node. If the checksums match, then the destination node sends an acknowledgement to 
the source node. If the source node does not receive an acknowledgement, then the source node 
will retransmit one or more packets to the destination node 

Col. 3, lines 29-53 of Mathur teaches that "[network] topological information, which is 
used for communicating and routing messages between nodes, resides in a CPU's working 
memory." System software is stored as a number of modules in a non-volatile storage device of 
a node. This cited portion finally teaches that the "network topological information is 
periodically maintained and updated to reflect changes in the configuration of the network." 

Nothing in these cited portions teaches or suggests that software version information is 
extracted from software packages that a destination node receives from a source node. 

Seq. No. 8501 19 



Ser. No. 10/725,190 filed November 29, 2003 
Douglas Wooff et al. - GAU 2193 (Vu) 
Docket No. 50325-0842 

In rejecting this feature of present Claim 10, the Final Office Action further states, "Note: 
packet reception of new software and for ILP for storage at node reads on extraction of package 
received based on version, checksum, packet time and topology of nodes etc." There are at least 
two problems with this assertion. First, Claim 10 does not recite extracting a package based on 
version. Instead, Claim 10 recites that software version information is extracted from one or 
more software packages. Second, it is unreasonable to interpret the mere packet reception of 
new software at a destination node and the destination node performing an IPL as including the 
specific limitation that software version information is extracted from one or more software 
packages . 

Fundamentally, Mathur lacks any teaching or suggestion that software version 
information is extracted (much less from software packages that are sent to a destination node ) 
and stored in persistent storage of the destination node. No destination node in Mathur is 
concerned with software version information of new software that it receives. Therefore, it is not 
surprising that Mathur fails to teach or suggest this feature of present Claim 10. Vishwanath is 
not cited for teaching or suggesting this feature of present Claim 10. 

Based on the foregoing, Mathur and Vishwanath fail to teach or suggest, both 
individually and in combination, all the features of Claim 10. Therefore, Claim 10 is patentable 
over the cited art. Reconsideration and withdrawal of the rejection of Claim 10 under 35 U.S.C. 
§ 103(a) is therefore respectfully requested. 

B . CLAIMS 21,32, AND 43 

Each of independent Claims 21, 32, and 43 is either a computer-readable storage 
medium, an apparatus, or a system claim. Each of Claims 21, 32, and 43 recites the features 
discussed above that distinguish present Claim 10 over Mathur and Vishwanath. Therefore, each 
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of Claims 21, 32, and 43 is patentable over the cited art for the reasons given above with respect 

to present Claim 10. 

C. CLAIMS 16, 27, 38, AND 48 

Each of Claims 16, 27, 38, 48 recites that the master node has the ability to categorize 
nodes into classes where all of the nodes in a particular class of nodes have the same software 
configuration. The Final Office Action cites col. 5, lines 3-27 and col. 3, lines 29-53 of Mathur 
for allegedly disclosing this feature. The Final Office Action further states, "Note: structure 
representing grouping of nodes according to some particular privilege configuration reads on 
class of nodes of same configuration but different processor." This is incorrect. 

The applicable cited portion of Mathur states: 

Advantageously, the system is implemented so that a distribution command is 
recognizable by a controller 100 only when it is issued with predefined access 
privileges . Furthermore, such privileges may be defined with an hierarchical 
structure so that the privilege required for a distribution process depends upon the 
importance of the software. 

(col. 5, lines 21-27; emphasis added) 

Thus, the privileges referred to in Mathur and in the Final Office Action are access privileges 

that are used to determine whether a distribution command (which identifies a source node and 

one or more destination nodes) will be recognizable, and thus executable. Contrary to the 

assertion in the Final Office Action, Mathur does not suggest a "structure representing grouping 

of nodes " (emphasis added). The Final Office Action fails to cite any portion of Mathur for 

teaching or suggesting such a structure or grouping. In fact, the cited portion of Mathur teaches 

the prior art approach of requiring a human user to identify each destination node of a software 

update (see col. 5, lines 1-3, 6-7, and 12-14). Vishwanath is not cited for teaching or suggesting 

this feature of Claims 16, 27, 38, and 48. 
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Based on the foregoing, Mathur and Vishwanath fail to teach or suggest, both 

individually and in combination, all the features of Claims 16, 27, 38, and 48. Therefore, each of 

Claims 16, 27, 38, and 48 is patentable over the cited art. Reconsideration and withdrawal of the 

rejection of Claims 16, 27, 38, and 48 under 35 U.S.C. § 103(a) is therefore respectfully 

requested. 

D. REMAINING DEPENDENT CLAIMS 

The dependent claims not discussed thus far are dependent claims, each of which depends 
(directly or indirectly) on one of the independent claims discussed above. Each of the dependent 
claims is therefore allowable for the reasons given above for the claim on which it depends. In 
addition, each of the dependent claims introduces one or more additional limitations that 
independently render it patentable. However, due to the fundamental differences already 
identified, to expedite the positive resolution of this case, a separate discussion of those 
limitations is not included at this time. The Applicant reserves the right to further point out the 
differences between the cited art and the novel features recited in the dependent claims. 
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II. CONCLUSIONS & MISCELLANEOUS 

For the reasons set forth above, all of the pending claims are now in condition for 
allowance. The Examiner is respectfully requested to contact the undersigned by telephone 
relating to any issue that would advance examination of the present application. 

A petition for extension of time, to the extent necessary to make this reply timely filed, is 
hereby made. If applicable, a law firm check for the petition for extension of time fee is enclosed 
herewith. If any applicable fee is missing or insufficient, throughout the pendency of this 
application, the Commissioner is hereby authorized to any applicable fees and to credit any 
overpayments to our Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Dated: June 6. 2008 /DanielDLedesma#57 181/ 

Daniel D. Ledesma 
Reg. No. 57,181 

2055 Gateway Place Suite 550 
San Jose, California 95110-1083 
Telephone No.: (408) 414-1080 ext. 229 
Facsimile No.: (408) 414-1076 
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